Several terms used below are defined as follows.
Transactional Faring System
A system which is able to compute and return fare quotes based on criteria requested by customers such as cheapest fares which apply for a destination, and best fares around a given date. Customers communicate with the transactional faring system, also referred to herein as a faring system, by means of transactions, i.e., a question (request for fare quote) followed by an answer (computed fare quote).
Fare Shopping Servers
Fare shopping servers are transactional servers which implement the products provided by the faring system. These servers are in charge of computing responses to queries made by the customer. There are two kinds of fare shopping servers: those dedicated to production, those dedicated to staging.
Production
The production is an operational facility (a computer system) where computations take place in order to return answers to the queries made by customers.
Staging
Staging is a relatively small and dedicated part of the faring system where a new product can be “validated” before being publicly made available to customers.
Operational Validation
When a new product has been validated as “functionally” valid, it goes though a series of tests under real life conditions to ensure it is also “operationally” valid (i.e., the impact of the product on the entire faring system is assessed). This is referred to as operational validation.
Shadow Traffic
A part of the traffic (i.e., requests from customers) is duplicated by the faring system to serve as a source of traffic for staging. The responses to this duplicated traffic (referred to as the shadow traffic) are not returned to customers.
The exemplary embodiments of this invention pertain most particularly to a transactional faring system whose purpose is to compute and return the best fare quotes based on criteria requested by customers: e.g., cheapest flights for a given destination and date, best flight fares around a given date, etc. These services are treated via fare shopping servers and accessed at a high rate (e.g., 90 million transactions per day).
Forecast changes in the faring system (e.g., new products, new volumes, new customers) are preceded by operational validations to ensure that the system can cope with the expected additional resource consumption (e.g., CPU, memory, database, network and other resources).
Operational validations are implemented by means of shadow traffic. That is to say, a part of the incoming customer traffic is duplicated from the production facility, without customer awareness. This duplicated, shadow traffic is then forwarded to a phantom operational facility referred to as the staging facility intended to test evolutions in the faring system. The effect of this shadow traffic run on the staging facility is then monitored and analyzed, while the original traffic is processed in a normal fashion by the production facility and returned to customers in a normal manner.
When introducing such production evolutions (e.g., new markets, new dimension, new products) cases can arise where the existing traffic is not suitable for operational validations. In such cases, it is necessary to simulate traffic in order to generate the inputs necessary for performing the validations.
It can be noted that several techniques might be envisioned to obtain relevant traffic for operational validations.
For example, one such possible technique would be to activate the evolution to one client at a time. In this possible approach the evolution (e.g., new product, new market) would be provided by the faring system and enabled only for a few clients in a first phase. It can be expected that the total resources consumed for processing the new service will have a limited impact on the overall production facility, and this cost can be analyzed precisely for creating accurate capacity planning.
However, this approach involves requesting clients to begin sending new traffic, which may be difficult. There is a risk that the traffic generated even by a few clients consumes more resources than expected and which can consequently endanger the operational stability of the faring system. Another drawback is that this scheme is not applicable in a case where it is a prerequisite to simultaneously open the new service to all clients.
Another possible technique would be to generate traffic from pre-recorded existing traffic. That is, one might record existing customer traffic for a given period of time and then transform this recorded traffic off-line (e.g., from disk) to make it appear as traffic that will target the new product. The transformed traffic can then be replayed manually while monitoring the resources consumed by the processing of the new service on the pre-recorded and transformed traffic.
However, replaying pre-generated traffic does not offer sufficient diversity, especially when the validation needs to be run over a long period of time. Moreover, is very difficult to mimic a pace of the replay which looks like actual traffic. At least these two shortcomings result in incomplete benchmarking and thus result in inaccurate capacity planning.
Another possible technique would be to convert the contents of incoming requests before they are processed. For example, a converter unit can be put in front of the real servers to modify the contents of incoming requests, for example, for enabling new features (i.e. new options) of a product provided by the faring system. No off-line storage need be involved in this process.
However, this approach is not practical in practice as its operation impacts customers of the production facility. For example, those clients whose traffic is modified can be given responses for different requests that what they have asked for, resulting in customer confusion and the possibility of alienating these customers.
Another approach would be to copying all the incoming requests from customers and use them on an adjacent server. This way, only realistic traffic is used without bothering the customers.
However, this method generates an important amount of data especially since customer traffic varies depending on the day and date, special offers, holidays and so on. So the server can actually be overloaded with much more traffic than it can handle, including a lot of useless information.